由于其规模、功能广泛性和极高的稳健性,Borg 仍然是 Google 内部主要的容器管理系统。▌Omega Omega 是 Borg 的后代,致力于改进 Borg 生态系统的软件工程。 Kubernetes 是开源的——与 Borg 和 Omega 形成鲜明对比,它们是纯粹作为 Google 内部系统开发的。 从Borg和Omega学习,Kubernetes是由一组可组合的构建块构建的,这些构建块可以很容易地被用户扩展。通用的API和对象元数据结构使这变得容易得多。 调节控制器循环的想法在整个Borg、Omega和Kubernetes中共享,以提高系统的弹性:它将所需状态(例如,标签选择器查询应匹配多少个pod)与观察到的状态(它可以找到的此类pod的数量)进行比较 ▌不要暴露原始状态 Borg、Omega和Kubernetes之间的一个关键区别在于他们的API架构。Borgmaster是一个整体组件,知道每个API操作的语义。
9.2.2 Borg[1] Borg是一个集群管理器,负责对来自几千个应用程序所提交的Job进行接收、调试、启动、停止、重启和监控,这些Job将用于不同的服务,运行在不同数量的集群中,每个集群各自可包含最多几万台服务器 Borg系统的使用者将向系统提交包含了一个或多个任务的Job,这些任务将共享同样的二进制代码,并在一个单元中执行,每个Borg单元由多台机器组成。 Omega是一种基于共享状态的调度器,该调度器将双层调度器中的集中式资源调度模块简化成了一些持久化的共享数据(状态)和针对这些数据的验证代码,而这里的“共享数据”实际上就是整个集群的实时资源使用信息。 这些功能全部由各个应用程序调度器自我管理和控制。 这样,如果你了解Mesos,那么就可知道,我们可以通过仅修改Mesos的Master将之改造成一个Omega。 3.优缺点 (1)优点:共享资源状态,支持更大的集群和更高的并发。
Borg 和 Omega 的经验教训:2009-2013 年 15 年前,即 2009 年初,我加入了 Google 的 Borg 控制平面团队。 2010 年,我启动了一个名为 Omega 的研发项目,以重新设计 Borg 以适应其使用方式,并更好地支持 Borg 周围的生态系统。 在很多方面,Kubernetes 更像是“开源 Omega”而不是“开源 Borg”,但它受益于从 Borg 和 Omega 中吸取的教训。 标签的来源(仅显示标签值以简化) Kubernetes 中的 cpu 和内存请求和限制规范 比 Borg 的更一致,并且与 Omega 的相比更简单。 早期容器产品 API 设计:2013 年下半年 所有这些来自 Borg 和 Omega 的经验使我们很快地开始了比赛。2013 年下半年,当我们开始讨论要构建哪种容器产品时,我开始勾勒 API。
Kubernetes Borg/Omega 历史主题 2:标签(Labels)。Borg 具有可在调度约束中使用的机器键/值属性。Borgmon 具有目标标签来传达应用程序拓扑、环境和区域设置。 Kubernetes Borg/Omega 历史主题 8:声明式配置和 Apply。在 Google 内部,Borg 最常用的配置方法是图灵完备的 Borg 配置语言 (BCL)。 @davidopp 曾是 Borg 和 Omega 中调度的 TL,也参与了 Kubernetes 中许多这些功能的开发。 Kubernetes Borg/Omega 历史主题 10:为了纪念 #KubeConEU 和 Kubernetes 开源五周年,我将从 Borg 和 Omega 团队的角度为起源故事添加更多视角。 Kubernetes Borg/Omega 历史主题 13: 优先级和抢占。某些工作比其他工作更重要和/或更紧急。Borg 将其表示为一个整数值:优先级。
由于 Borg 的规模、功能的广泛性和超高的稳定性,Borg 在谷歌内部依然是主要的容器管理系统。 2013 年,Google 为了构建一个更为一致的基础架构,Google 借鉴和吸收 Borg 上的优秀理念和能力,推出了新一代集群管理系统 Omega(Google 第二个集群管理系统),Omega 许多 Omega 的创新(包括多个调度器)都被收录进了 Borg。 2014 年,Kubernetes 开源。 Kubernetes 是 Google 开发的第三个集群管理系统与 Borg、Omega 完全是谷歌内部系统项目,Kubernetes 是开源的,对 Docker 等主流容器技术天然友好支持,同时具备 Borg 和 Omega 的众多优势和能力。
核心是 parallelism, shared state, optimistic concurrency control. borg 至少15年历史,论文发表于 2015 borg 中的概念和 k8s 和 mesos 的主要不同是让 scheduler 自己决策,而不是约束框架,然后用一种乐观的方式来解决冲突。 omega 的评估使用的是模拟的结果,他的实际意义有点可疑。 borg 中的概念和 kubernetes 非常相似,论文中描述的实现方式也和 kubernetes 的实现基本相同。 也在变得非常复杂),有理由相信,k8s 至少和 borg 一样先进。 , Borg: A Survey mesos-架构 mesos 论文 borg 论文 omega 论文 进击的Kubernetes调度系统(一):Scheduling Framework 进击的Kubernetes
Borg是一个集群管理器,它负责对来自于几千个应用程序所提交的job进行接收、调试、启动、停止、重启和监控,这些job将用于不同的服务,运行在不同数量的集群中,每个集群各自都可包含最多几万台服务器。 Borg的目的是让开发者能够不必操心资源管理的问题,让他们专注于自己的工作,并且做到跨多个数据中心的资源利用率最大化。下面这张图表描述了Borg的主要架构: ? 一个网站可以包含多个大楼和集群。 Job:是一种在单元的边界之内进行执行的活动。这些job可以附加一些需求信息,例如CPU、OS、公开的IP等等。 Borg系统的使用者将向系统提交包含了一个或多个任务的job,这些任务将共享同样的二进制代码,并在一个单元中进行执行,每个Borg单元由多台机器组成。 Google还有一个名为Omega的集群管理器,这里简单地描述一下Omega: Omega支持多个并行的、特定的“垂直任务”,其中每一个垂直任务基本类似于一个Borgmaster,只是缺少了持久化存储与连接分片的功能
对于外部的软件,比如GAE和GCE,Google的做法是让它们运行在虚拟机(KVM)上,KVM进程被作为Borg的task运行。也就是说,KVM运行在Borg之上。 对于程序的调试,全都通过Borg来操作,Borg会让用户的命令在和被操作的tasks同一个容器下的shell中运行。 而latency-sensitive和rest是Borglet在主机的task层面上看的,是一个进程的维度。 另外,Borg中,主机的资源其实是超卖的(不然怎么节约资源),包括可压缩和不可压缩的资源。 因此,Borg将资源分为两大类:可压缩资源(compressible resources)和不可压缩资源(non-compressible resources)。 Borg调度者使用申请值(限制值)来计划prod tasks(分配时按照限制来算),因此它们从不依靠再生资源,也不会超额分配资源。
由于 Borg 的规模、功能的广泛性和超高的稳定性,Borg 在谷歌内部依然是主要的容器管理系统。 2013 年,Google 为了构建一个更为一致的基础架构,Google 借鉴和吸收 Borg 上的优秀理念和能力,推出了新一代集群管理系统 Omega(Google 第二个集群管理系统),Omega 许多 Omega 的创新(包括多个调度器)都被收录进了 Borg。2014 年,Kubernetes 开源。 Kubernetes 是 Google 开发的第三个集群管理系统与 Borg、Omega 完全是谷歌内部系统项目,Kubernetes 是开源的,对 Docker 等主流容器技术天然友好支持,同时具备 Borg 和 Omega 的众多优势和能力。
摘要:本文以资源分配理念:拍卖、预算、抢占出发,引出Borg、Omega、Mesos、Kubernetes架构、数据、API的特点比较。 从中不难发现Borg是始祖,后来的Mesos、Omega、Kubernetes、Zeus等都延续着Borg的某些重要特征,而又随技术发展,引入新的特征。 和Borg Omega一样,都有一个共享的持久化状态存储模块,用于实现资源状态一致性。 Omega Omega 基于Borg发展起来的Google新一代系统,Omega论文并没有给出详细API说 明。Omega重点在对比过去的架构和新架构的优势,API猜测基本延续了Borg的相关功能。 当讨论Kubernetes的时候,自然想到Mesos的冲击力,并随着Docker容器技术的兴起、云计算的发展,人们开始忘记Omega,似乎只有Mesos和Kubernetes,以及共同的祖先Borg。
在Google已经公开发表的基础设施体系论文中,Borg项目当仁不让地位居整个基础设施技术栈的最底层。 这幅图,来自于Google Omega论文的第一作者的博士毕业论文。 在这个图里,你既可以找到MapReduce、BigTable等知名项目,也能看到Borg和它的继任者Omega位于整个技术栈的最底层。 /Omega系统的设计与经验。 更重要的是,这些特性在开源社区落地的过程中,又在整个社区的合力之下得到了极大的改进,修复了很多当年遗留在Borg体系中的缺陷和问题。 项目的理论优势 才在短短几个月内迅速站稳了脚跟 进而确定了一个如下所示的全局架构 可以看到,Kubernetes项目的架构,跟它的原型项目Borg类似,都由Master和Node两种节点组成,分别对应着控制节点和计算节点
docker/aufs/mnt 上的 rootfs 2. container runtime:一个由 Namespace+Cgroups 构成的隔离环境 k8s: 核心特性的提出,很多都来Borg /Omega 系统的设计与经验并修复了很多当年遗留在 Borg 体系中的缺陷和问题 k8s架构 image.png 由master和node两种节点组成,角色分别是控制和计算; master节点:控制节点 这些关系的处理,才是作业编排和管理系统最困难的地方。 eg:web应用和数据库之间的交互,clb和后端服务的代理,web应用和日志组件的文件交换等 Kubernetes 项目最主要的设计思想是,从更宏观的角度,以统一的方式来定义任务之间的各种关系,并且为将来支持更多种类的关系留有余地 按照用户的意愿和整个系统的规则,完全自动化地处理好容器之间的各种关系。
CNCF 有一张云原生全景图:https://github.com/cncf/landscape 在这个全景图里已经有 200 多个项目和产品了,这些项目和产品也都是和 CNCF 的观点所契合的。 2014 年的时候,Kubernetes 项目发布,其意义在于 Google 将内部的 Borg/Omega 系统思想借助开源社区实现了“重生”,并且提出了“容器设计模式”的思想。 而 Google 之所以选择间接开源 Kubernetes 而不是直接开源 Borg 项目,其实背后的原因也比较容易理解:Borg/Omega 这样的系统太复杂了,是没办法提供给 Google 之外的人使用 ,但是 Borg/Omega 这样的设计思想却可以借助 Kubernetes 让大家接触到,这也是开源 Kubernetes 的重要背景。 因此,对于云友好的基础设施是随时可以替换和更换的,这就是因为容器具有敏捷和一致性的能力,也就是云时代的应用基础设施。
需要的资源大小, CPU/Memory 每个主机总资源/剩余资源大小 尽量分散在不同的主机/可用区,提升容灾能力 是否考虑就地重启 Pod 是否必须调度到一些合适的机型 (例如有SSD硬盘) Pod 是否最好和其他关系紧密的 Spark-Operator,用于更方便的创建 Spark Job Custom Resources Operator 如果要开发自己的 Operator,可以参考 Operator Framework 扩展阅读 Borg , Omega, and Kubernetes,强烈推荐阅读,了解 Kubernetes 在Google内部的发展过程 Kubernetes 组件 Kubernetes 架构 Large-scale cluster management at Google with Borg Omega: flexible, scalable schedulers for large compute clusters Linux
10年前,Google更发明了用来管理全球最大规模丛集的排程和服务管理工具Borg。 直到现在,Google基础架构副总裁Eric Brewer表示,以Container封装应用、可动态维运、微服务架构导向的云端原生应用风潮开始兴起,Google遂将用来管理和部署大规模Container 的Borg和Omega等管理平台的经验,重新开发成了一套开源容器丛集管理软件Kubernetes,并推出以Kubernetes打造的Google云端平台提供的GKE(Google Container Engine 这提供了可程序化和高弹性的部署配置,可以在开发常见的应用部署阶段之前,提供一种新的组合式部署方法称为Construction,在部署阶段仍然可以实时变更Config配置,例如由程序自动依据部署环境在测试环境
共享状态调度架构 两级调度架构在资源视图、调度并发度方面存在的问题,业界提出了共享状态调度架构,其典型代表是 Google Borg 和 Omega。 VStation 的调度架构与优化实践 调度架构 VStation 的调度架构,本质上与 Google Borg/Omega类似,采用共享状态调度架构,众多调度器采用无锁乐观并发机制、基于全局资源视图进行调度决策 另一方面,针对 Google Omega 存在的隐患,对调度冲突进行优化。 ? 总体来说,调度过程包括资源同步、调度决策和提交调度结果三个环节。 相比 Google Omega 重新调度的做法,对调度冲突的处理代价显著减小。在公有云海量并发创建的场景下,VStation 在调度决策和调度吞吐率进行权衡,选择次优解来保证调度吞吐率。 ;为了解决资源数据量级过大的问题,采用私有缓存和增量更新的方法,这些都与 Google Borg 的做法不谋而合。
Kubernetes的出现与发展 Kubernetes是Google公司早在2014年就发布开源的一个容器基础设施编排框架,和其他拍脑袋想出来的技术不同,Kubernetes的技术是有理论依据的,即:Borg Borg是Google公司整个基础设施体系中的一部分,Borg是Google公司整个基础设施体系中的一部分,Google也发布了多篇关于Borg的论文作为其理论支持。 因此Borg系统一直以来都被誉为Google公司内部最强大的“秘密武器”,也是Google公司最不可能开源的项目,而Kubernetes就是在这样的理论基础上开发的。 下图是Google Omega论文所描述的Google已公开的基础设施栈。 ? 开源vs闭源 ? 面对k8s的出现,一场Docker和k8s之间的容器之战就此打响。 在这场对抗之初,由于Kubernetes开发灵感和设计思想来源于Borg,Kubernetes项目在刚发布时就被称为曲高和寡。
Borg通过准入控制,高效的任务打包,超额的资源分配和进程级隔离的机器共享,来实现超高的资源利用率。 Borg作业配置与Aurora配置文件相似[6]。 图2说明了作业和任务在其生命周期中经历的状态。 ? 图2:作业和任务的状态图。 用户可以触发提交,终止和更新转换。 要启用此功能,Borg将为每个任务创建一个稳定的“Borg name service”(BNS)名称,其中包含单元名称,作业名称和任务编号。 3.Borg体系结构 Borg单元由一组机器,一个称为Borgmaster的逻辑中央控制器和单元中每台机器上运行的称为Borglet的代理进程构成(参见图1)。 Borg的所有组件都用C ++编写。 这在灵魂上与在Omega [69]中使用的乐观并发控制非常相似,事实上,我们最近为Borg添加了针对不同工作负载类型使用不同调度程序(schedulers)的能力。
它不仅决定了药物与靶点之间的相互作用强度,还对药物筛选、优化和临床应用具有重要指导意义。然而,由于药物化合物和潜在靶点数量庞大,通过生物实验全面测量DTA既费时又费力。 2025年1月10日,ACS Omega上发表的文章Deep Drug–Target Binding Affinity Prediction Based on Multiple Feature Extraction 2 现有方法的局限性 现有的DTA预测方法大致分为基于序列的模型和基于图结构的模型。 基于序列的模型直接将药物和靶点表示为一维序列输入模型,例如DeepDTA和AttentionDTA。 BTDHDTA引入Highway网络,通过门控机制过滤和融合全局与局部特征,同时引入一维卷积捕获药物和靶点间的细粒度交互。 ACS Omega. https://doi.org/10.1021/acsomega.4c08048
本月,Linux 基金会和 edX 发布了 2021 年开源工作报告。 基于对 200 名技术招聘经理和 750 名开源专家的调查数据,该报告揭示了开源职业的最新趋势、需要哪些技能、激励开源专业人士的因素、雇主如何吸引和留住顶尖人才、COVID-19 大流行如何影响了招聘和工作场所 首先我们回顾下云原生技术发展历史: 2013 年,Docker 项目发布 使得全操作系统语义的沙盒技术唾手可得,对传统的 PaaS 产业“降维打击” 2014 年,Kubernetes 项目发布 Google Borg /Omega 系统思想借助开源社区“重生”,“容器设计模式”的思想正式确立 2015~2016 年,容器编排“三足鼎立” Docker Swarm、Mesos、Kubernetes 在容器编排领域展开角逐 Kubernetes 是 Google 开源的一款容器编排工具,它是诞生在 Google 内部运行 N 多年的 Borg 系统之上的产物,因此其成熟度从其诞生初期就广泛受到业界的关注,并且迅速成为编排工具市场的主流